System, method, and computer program product for remotely determining the configuration of a multi-media content user

ABSTRACT

A method for remotely determining the configuration of a computer of a multimedia content user includes sending player detection code the user&#39;s computer and receiving configuration information regarding the user&#39;s computer. A method of determining a connection speed of a computer includes determining a size of a timing block based on an estimated bandwidth and retrieving the timing block. The connection speed is determined based on the timing block size and the times at which transfer begins and ends.

PRIORITY

This application is a continuation-in-part of U.S. patent applicationSer. No. 09/986,683, filed Nov. 9, 2001, and published May 15, 2003 asUS published application no 2003/0093507, which is hereby incorporatedby reference; and this application claims priority to United Statesprovisional application serial number not yet assigned (Express Mailnumber EV331871969US), filed Oct. 31, 2003, by inventor Jody Shapiro,entitled, “System, Method, and Computer Program Product for RemotelyDetermining the Configuration of a Multi-Media Content User”.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention described herein relates to information systems, and moreparticularly to detection of multimedia content client configurationinformation.

2. Related Art

Given the availability of data networks and the availability ofhigh-speed data connections, it is now commonplace for end users toaccess multi-media content. A number of web sites now offer audio andvideo to users. Ideally, the user simply clicks on a link or controlpresented in a web page, and one or more multi-media files aredelivered. If the user has the appropriate hardware and softwareconfiguration, the file can then be played.

There are currently a significant variety of user configurations,however. Some users have INTEL based personal computers (PCs), whileothers may have APPLE MACINTOSH computers. Different operating systemsare also present. Some users will have a version MICROSOFT WINDOWS, fromMICROSOFT, Inc., while others have a version of MAC OS, from APPLE, Inc.Moreover, each of these operating systems now has several versions inthe user community. In addition, a number of software programs are nowavailable to play multimedia on the computers of users. These playersinclude QUICKTIME (from APPLE, Inc.), REALPLAYER (from REALNETWORKS,Inc.), and WINDOWS MEDIAPLAYER (from MICROSOFT, Inc.). Moreover, each ofthese players has several versions that are currently available in theuser community. Finally, different users may be operating at differentdata rates. Some users may have a high speed broadband connection, whileothers may have a 56K modem connection.

Given this variety of platforms, operating systems, players, and datarates, a content provider is faced with the problem of how to format thecontent to be delivered. Incorrect formatting would result in thedelivery of content that was incompatible with a user's configuration.This could result in content that is unusable, if the content is usable,the content may be in a format that fails to take advantage of all thefeatures available in the user's configuration, such that the content,as experienced by the user, is not as rich as it could be.

In the past, content providers have addressed this problem by choosingsome set of common user configurations. The provider, for example, mightidentify the most common media players and versions thereof. Theprovider formats the content for each of these players and stores theseassorted versions of the content. The provider would then develop a menuto be provided to the user, in effect asking which media player the userhas, or, if the user has more than one, which player is preferred by theuser. The user then makes a selection, and the content that has beenpre-encoded in the selected format is delivered to the user.

This solution has limitations. First, it is relatively inflexible. Thenumber of options is limited. A user's specific configuration may nothave been presented as an option in the menu. And if an end user hasmore than one media player available to him, the user's preferred choicemay not have been listed as an option. Also, the solution above requiresuser input each time. The user might not want to be queried. The usermay instead prefer that formatting be resolved for him. In othersituations, the user might not know the information requested by themenu. The user may not know what version of a media player he has. Thissolution also requires that a content provider change their menus andre-encode content whenever new players (Or new versions of existingplayers) become prevalent. The above solution, therefore, is inflexibleand burdensome to both the user and the provider.

What is needed, therefore, is a way to determine a user's configurationso as to provide the user with content in a compatible format that leadsto the optimal viewing experience. In addition, determination of theconfiguration should be made in a manner that minimizes the need foruser input and is otherwise user-friendly. Moreover, an efficient way todetermine the connection speed of a user is desired.

SUMMARY OF THE INVENTION

A method is provided for remotely determining the configuration of acomputer of a multimedia content user. The method includes sendingplayer detection code to the user's computer. Configuration informationis received regarding the user's computer including informationregarding OS version, web browser version, hardware platform, userinterface language type, encoding format, or compression algorithm, orcombinations thereof. The method may include setting a cookie at theuser's computer to a domain of a delivery management server, performedbefore the receiving, and wherein the configuration information isreceived in the cookie.

A method for remotely determining the configuration of a computer of amultimedia content user is further provided including sending playerdetection code to the user's computer, receiving configurationinformation regarding the user's computer, and sending a modifiedinformation header instruction.

The method may also include sending unique client ID. The instructionsmay be received after the information is sent, and the modifiedinformation may include some information that was not included in thesent information and/or the modified information may exclude someinformation that was included in the sent information. The modifiedinformation header instruction may also be sent prior to the receiving,and the configuration information received may be prepared according tothe modified information header instruction.

The received configuration information may include one or moreadaptations such as a hardware adaptation and/or a user interfaceversion adaptation. The modified header information instruction may beprepared according to the adaptation information.

A method is further provided for remotely determining the configurationof a computer of a multimedia content user including receiving at auser's computer player detection code from a second computer, sending tothe second computer configuration information regarding the user'scomputer, and receiving a modified information header instruction.

An unique client ID may be received. A client ID pointer address may beappended with configuration information for sending to the secondcomputer, Modified header information may be prepared based on thereceived header instruction. The modified header information withappended client ID may be sent to the second computer. A furtherconfiguration information request may be received prior to the sendingof the modified header information. The instruction may be receivedafter the configuration information is sent. The modified informationmay include some information that was not included in the sentinformation and/or may exclude some information that was included in thesent information. The instruction may also be received before theconfiguration information is sent. The configuration information sentmay be prepared according to the modified information headerinstruction. The configuration information may include one or moreadaptations such as a hardware adaptation and/or a user interfaceversion adaptation, and the modified header information instruction maybe prepared according to the adaptation information.

A method is also provided, for determining a connection speed of acomputer including determining a size of a timing block based on anestimated bandwidth, marking the time at which transfer of the timingblock begins, marking the time at which transfer of the timing blockends, and determining the connection speed based on the determinedtiming block size and the times at which transfer begins and ends.

A further method that is provided for determining a connection speed ofa computer includes receiving a timing block of data having a knownsize, receiving a start time at which transfer of the timing block is tobegin, beginning the timing block transfer at the start time, markingthe time at which transfer of the timing block ends, and determining theconnection speed based on the timing block size and the times at whichtransfer begins and ends.

In each case, the timing block size may be determined by fetchingestimated bandwidth information, determining an estimated time toretrieve data for determining connection speed with adequate resolution,and determining the timing block size that will take the determinedestimated time to retrieve. The timing block may be received in a markuplanguage comment as part of a preferences page. The method may alsoinclude storing the connection speed in a cookie. The method may includesending the cookie to a delivery management server. The timing block maycomprise random data.

According to a further aspect of the invention, a method for remotelydetermining the configuration of a computer of a multimedia content useris provided. This method includes sending player detection code to theuser's computer, receiving configuration information regarding theuser's computer, and determining a type of digital rights managementinformation on the user's computer based on the received configurationinformation.

One or more processor readable storage devices are also provided havingprocessor readable code embodied thereon. The processor readable code isfor programming one or more processors to perform a method for remotelydetermining the configuration of a computer of a multimedia content userand/or for determining a connection speed of a computer, in accordancewith any of the above.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated herein and form a partof the specification, illustrate the present invention and, togetherwith the description, further serve to explain the principles of theinvention and to enable a person skilled in the pertinent art to makeand use the invention.

In the drawings:

FIG. 1 illustrates the general architecture of an embodiment of theinvention.

FIG. 2 is a block diagram illustrating the computing environment of anembodiment of the invention.

FIG. 3A is a flow chart illustrating the overall process of anembodiment of the invention.

FIG. 3B is a flow chart illustrating server-side request processing inaccordance with an embodiment including receiving a delivery managerHTTP request.

FIG. 3C is a flow chart illustrating server-side request processing inaccordance with an embodiment including receiving a detection URL HTTPrequest.

FIG. 3D is a flow chart illustrating further request processingaccording to an embodiment of the invention.

FIG. 4A is a flow chart illustrating the process of media playerdetection, according to an embodiment of the invention.

FIG. 4B, consisting of FIGS. 4B1-4B2, is a flow chart illustratingclient-side windows media player (WMP) detection in accordance with anexemplary embodiment of the invention.

FIG. 4C, consisting of FIGS. 4C1-4C3, is a flow chart illustratingclient-side RealPlayer (Real) detection in accordance with anotherexemplary embodiment of the invention.

FIG. 4D, consisting of FIGS. 4D1-4D2, is a flow chart illustratingclient-side QuickTime (QT) detection in accordance with an exemplaryembodiment of the invention.

FIG. 5A is a flow chart illustrating the process of presenting apreferences page to the user, according to an embodiment of theinvention.

FIG. 5B is a flow chart generally illustrating a bandwidth detectionmethod according to an embodiment of the invention.

FIGS. 6A-6C are a flowchart that describes a routine for accessing mediacontent according to an embodiment of the present invention.

FIG. 7 depicts an exemplary transcoder that may be used in accordancewith embodiments of the present invention.

FIG. 8 is a table showing exemplary transcoding source types anddestination types for various publishing variables according to anembodiment of the present invention.

FIG. 9 is a table showing exemplary client environment variable typesaccording to an embodiment of the invention.

Preferred embodiments of the present invention will now be describedwith reference to the accompanying drawings, in the drawings, likereference numbers indicate identical or functionally similar elements,

INCORPORATION BY REFERENCE

What follows is a cite list of references each of which is, in additionto that which is described as background of the invention, the abstractand the invention summary, hereby incorporated by reference into thedetailed description of the preferred embodiments below, as disclosingalternative embodiments of elements or features of the preferredembodiments not otherwise set forth in detail below. A single one or acombination of two or more of these references may be consulted toobtain a variation of the preferred embodiments described in thedetailed description herein:

U.S. Pat. No. 3,394,352, issued July 1968; U.S. Pat. No. 3,937,881,issued February, 1976; U.S. Pat. No. 5,657,015, issued August, 1997;U.S. Pat. No. 6,593,860, issued Jul. 15, 2003; U.S. Pat. No. 6,407,680,issued June, 2002; U.S. Pat. No. 6,466,939, issued Oct. 15, 2002; U.S.Pat. No. 3,928,330, issued Jul. 27, 1999; U.S. Pat. No. 6,317,134,issued Nov. 13, 2001; and U.S. Pat. No. 6,070,002, issued May 30, 2000;and

United States published applications no. 2003/0158913, published Aug.21, 2003, 2003/0093507, published May 15, 2003, 2002/0099858, publishedJul. 25, 2002, 2002/0099770, published Jul. 25, 2002, and 2002/0091800,published Jul. 11, 2002; and

U.S. patent application Ser. No. 10/644,602, filed Aug. 20, 2003; andChapman, Nigel et al., “Digital Multimedia,” John Wiley & Sons, Ltd.,Copyright 2000; and

Murray, James D. et al., “Encyclopedia of Graphics File Formats: SecondEdition,” O'Reilly & Associates, Inc., Copyright 1994, 1996,

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Overview of PreferredEmbodiments

A system, method, and computer program product for determining theconfiguration of an end user's computer system. In particular, the mediaplayers and network connection speed of the user are determined. Thisconfiguration information is that received by a second computer,preferably a delivery management server. The configuration informationis used to format multi-media content for delivery to the user. Becausethe content is formatted according to the configuration information, thecontent is compatible with the user's configuration. The configurationdetermination process involves server contact code placed in the webpage of the content provider. When the web page is loaded by the user,the server contact code directs the browser to retrieve code from thedelivery management server. When the code is executed by the user, themedia player of the user is determined. This information is saved incookies at the user and is sent to the delivery management server. Ifthe configuration information is indeterminate or incomplete, the useris presented with a preferences page in which the user can indicate theconfiguration. The preferences page also contains a mechanism fordetermining the connection speed of the user. The preferences page canalso make specific recommendations to the user, recommend that the userchoose a specific media player. The preferences page contains a block ofdata having a known size. The time required to transfer the block ismeasured, and the connection speed is then calculated and provided tothe delivery management server.

In accordance with a preferred embodiment, the configurationdetermination process involves server contact code that is placed in theweb page of the content provider. When the web page is loaded by theuser, the server contact code directs the browser to retrieve scriptsfrom the delivery management server. When the scripts are executed bythe user, the media player of the user is determined. This informationis saved in cookies at the user and is sent to the delivery managementserver. The configuration information can then be used by a transcoderthat formats the media content according to the configurationinformation.

If the configuration information is indeterminate or incomplete, theuser is presented with a preferences page in which the user can indicatethe configuration. This configuration, as determined through thepreferences page, is also stored in cookies and sent to the deliverymanagement server to allow formatting of content. The preferences pagecan also make specific recommendations to the user, e.g., recommend thatthe user choose a specific media player.

Description of the Preferred Embodiments

The preferred embodiments described herein relate to a system, method,and computer program product that allows the remote determination of auser's computer system configuration. This allows multimedia contentdestined for that computer to be formatted in a manner compatible withthe user's configuration. If sufficient configuration information isobtained, the content can be formatted so as to provide the bestpossible media experience for the user.

Note that in the description that follows, the concept of a user'scomputer is defined broadly to include the full range of programmable orprogrammed-devices. A user's computer can be, but is not limited to, apersonal computer or other workstation, a laptop, a palmtop, a personaldata assistant, or a cell phone.

In accordance with a preferred embodiment, server contact code iscontained in a web page sent by a content provider to the user. Theserver contact code retrieves one or more scripts from a deliverymanagement server. The scripts enable the determination of configurationinformation of the user's computer system, in an embodiment of theinvention, the configuration information comprises the identity andversion of the user's media player(s). The configuration information isthen returned to the delivery management server. The configurationinformation can then be used to format the multi-media contentappropriately. In an embodiment of the invention, configurationinformation is also stored locally at the user's computer in the form ofcookies. In subsequent hypertext transfer protocol (I (HTTP) requests,the cookies can be sent to the delivery management server as a way ofconveying the configuration information.

If the configuration information is determined to be incomplete orpotentially outdated, an additional web page is opened. This is apreferences page, where the user can specify his configuration (e.g.,his available or preferred media player type and version, and/or apreferred connection speed) to the delivery management server. Thepreferences page can also be used to recommend that the user choose aspecific media player.

In accordance with a preferred embodiment, a preferences page includes ablock of data of known size. This block is transferred into the user'scomputer as a part of the preferences page. The time required totransfer this block of data is measured in order to determine theconnection speed of the user's computer. The connection speed representsan additional piece of configuration information. The connection speedis also stored locally at the user's computer in the form of a cookie.This cookie can also be sent to the delivery management server as a wayof conveying the user's connection rate to the delivery managementserver.

The system of the preferred embodiment basically supports detection oftwo things: server-to-diem connection speed (bandwidth), and mediaplayers (including player versions) installed on the client. In regardsto connection speed detection, only server-to-client estimation isdesired because the media stream will be sent by the server to theclient. Some media player control channel data will be sent from theclient back to the server, but the quantity of data is vastly smallerthan the actual media data being sent from the server.

When detecting media players, the ideal is to be able to detect all ofthe following: media players installed (e.g. QuickTime, Windows MediaPlayer, RealPlayer, etc.), versions of installed media players (e.g.,QuickTime 5.0.2, Windows Media Player 6.4, RealPlayer 8.0), andindividual audio and video codecs installed in each media player(Sorenson v3 for QuickTime, Windows Media Video V8, Sony ATRAC forRealPlayer, etc).

For Generic Media's application, it is also useful to know the detailsof the client environment. Useful information includes operating systemversion, web browser version, hardware platform, and preferred userinterface language. Some of this information is easily obtained(typically as part of an HTTP header that's sent by the client to theserver), while other information is either more difficult to obtain ortime consuming to obtain and is best done periodically (not for everyrequest). In these cases, it's desirable to save the detectedinformation (as well as any user preferences) in a cookie stored in theclient's web browser. When requests are made to Generic Media servers,the web browser will automatically send affiliated cookie data to theserver.

Detection System

An overall architecture in accordance with a preferred embodimentincludes server contact code embedded in a web page of a contentprovider. The server contact code directs the user's browser to adelivery management server, which sends one or more scripts to the user.Execution of the scripts can identify the type and version of the user'smedia player. This delivery management server receives this informationfrom the user. The configuration information can eventually be used toformat multi-media content for delivery to the user.

One embodiment of the system of the invention is illustrated in FIG. 1.A content provider 105 is shown delivering information to a user 110.Included in web page 115 is server contact code 120. When the browser ofuser 110 accesses server contact code 120, the browser establishescontact with delivery management server 125 and asks for one or moreplayer detection scripts 140. Server 125 responds by sending scripts 140to user 110. In a manner that will be described in greater detail below,the scripts 140, when executed, determine configuration information 135for user 110. In an embodiment of the invention, this configurationinformation is stored with user 110 by a process of setting cookies thatcontain configuration information 135. The cookies are retained by user110, and when user 110 makes the HTTP request 130 to access the content,configuration information 135, in the form of the cookies, is sent todelivery management server 125. A transcoder (not shown) formats themulti-media content in a manner specified by configuration information135. The resulting formatted content can then be delivered to user 110through a streaming server (not shown).

If configuration information 135 is not available (or otherwise requiresclarification), an additional script, provided to user 110 as one of thescripts 140, opens a new window that loads a preferences web page 150.With this page, user 110 can explicitly identify configurationinformation 135 (e.g., the player type and version) through a userinterface in preferences page 150. As before, the configurationinformation 135 can be retained at user 110 in the form of cookies andforwarded to delivery management server 125.

In an embodiment of the invention, a recommendation can be made by thedelivery management server to the user, through the preferences page150, as to a particular media player that the user can or should select.Such a recommendation is based on what is known about the user'soptions. In such an embodiment of the preferences page 150, therecommendation can be conveyed through a portion of the page. Thisportion can be thought of as a server interface, since the servercommunicates to the user through this interface.

As will be described in greater detail below, the preferences pageincludes a block of data 155 having a known size. The transfer of theblock 155 is timed in order to determine the connection speed of theuser 10. In an embodiment of the invention, block 155 (known hereinafteras the timing block) is incorporated in an HTML comment in thepreferences page 150.

In some contexts of the invention, the delivery management server 125 isone of a set of such servers. Here, the set of delivery managementservers services a community of users by means of the inventiondescribed herein. Given a user's request for content, the user would beassigned to a specific delivery management server through a selectionmechanism that balances the load created by multiple users.

In an embodiment of the invention, the functionality of deliverymanagement server 125 is embodied in a viewer web server interface to atranscoding engine. The transcoding engine, in general, receives contentfrom a content provider and formats (“transcodes”) the content in amanner that makes it usable by user 110. The viewer web server interfaceis a network interface between the transcoding engine and the user 110,that allows content to be requested by user 110. The viewer web serverinterface receives and processes a content request from the user 110,thereby initiating the transcoding and delivery of the requested contentto the user 110. The viewer web server interface sends a reply to user110's request, redirecting the user 110 to an appropriate streamingserver from which to receive the requested media content. Formatted(“transcoded”) content is then streamed to the user 110 by a streamingserver and/or proxy server (also a part of the transcoding engine). Sucha transcoding engine is described in greater detail in U.S. Pat. Nos.6,407,680 and 6,593,860, and incorporated by reference herein in itsentirety. Alternatively, the delivery management server 125 and theviewer web server interface can be implemented as separate servers.

Note that the invention described herein can be implemented in a varietyof organizational contexts. For example, the transcoding and deliverymanagement operations described above can be performed by a deliverymanagement service. This service may be, for example, a separateorganization or business entity independent of the content provider 105.In this case, web page 115 may be developed by content provider 105independently of the delivery management service, Web page 115 couldthen include a logo or other branding images, and/or a “look and feel”specific to content provider 105. Likewise, preferences page 150, thoughdelivered to user 110 by delivery management server 125, could also bedeveloped by content provider 105 independent of the delivery managementservice.

Independence of the delivery management service and content provider 105would also allow the delivery management service to make service changeson its own. The delivery management service would be free to upgrade itsservice by adding or otherwise modifying functionality. Player detectionscripts 140 could be improved, for example, so as to make the playerdetection process faster or more comprehensive, independent of aspecific content provider 105.

The transcoding process could also be upgraded independent of contentprovider 105, to accommodate additional media formats or to providefaster transcoding, for example. The delivery management server 125 maybe implemented using hardware, software or a combination thereof. Inparticular, server 125 may be implemented using a computer system orother processing system. An example of such a computer system 200 isshown in FIG. 2. The computer system 200 includes one or moreprocessors, such as processor 204. The processor 204 is connected to acommunication infrastructure 206 (e.g., a bus or network). Varioussoftware embodiments can be described in terms of this exemplarycomputer system. After reading this description, it will become apparentto a person skilled in the relevant art how to implement the inventionusing other computer systems and/or computer architectures.

Computer system 200 also includes a main memory 208, preferably randomaccess memory (RAM), and may also include a secondary memory 210. Thesecondary memory 210 may include, for example, a hard disk drive 212and/or a removable storage drive 214, representing a magnetic tapedrive, an optical disk drive, etc. The removable storage drive 214 readsfrom and/or writes to a removable storage unit 218 in a well knownmanner. Removable storage unit 218 represents a magnetic tape, opticaldisk, etc. As will be appreciated, the removable storage unit 218includes a computer usable storage medium having stored therein computersoftware and/or data.

Secondary memory 210 can also include other similar means for allowingcomputer programs or input data to be loaded into computer system 200.Such means may include, for example, a removable storage unit 222 and aninterface 220. Examples of such may include a program cartridge andcartridge interface (such as that found in video game devices), aremovable memory chip (such as an EPROM, or PROM) and associated socket,and other removable storage units 222 and interfaces 220 which allowsoftware and data to be transferred from the removable storage unit 222to computer system 200.

Computer system 200 may also include a communications interface 224.Communications interface 224 allows software and data to be transferredbetween computer system 200 and external devices. Examples ofcommunications interface 224 may include a modern, a network interface(such as an Ethernet card), a communications port, a PCMCIA slot andcard, etc. Software and data transferred via communications interface224 are in the form of signals 228 which may be electronic,electromagnetic, optical or other signals capable of being received bycommunications interface 224. These signals 228 axe provided tocommunications interface 224 via a communications path (i.e., channel)226. This channel 226 carries signals 228 into and out of computersystem 200, and may be implemented using wire or cable, fiber optics, aphone line, a cellular phone link, an RF link and other communicationschannels. In an embodiment of the invention, signals 228 can conveyinformation required by the delivery management server 125, such as HTTPrequest 130 and configuration information 135. Signals 228 can alsoconvey information to user 110, such as scripts 140 and preferences page150.

In this document, the terms “computer program medium” and “computerusable medium” are used to generally refer to media such as removablestorage drive 214, a hard disk installed in hard disk drive 212, andsignals 228. These computer program products are means for providingsoftware to computer system 200. The invention is directed in part tosuch computer program products.

Computer programs (also called computer control logic) are stored inmain memory 208 and/or secondary memory 210. Computer programs may alsobe received via communications interface 224. Such computer programs,when executed, enable the computer system 200 to perform the features ofthe present invention as discussed herein. In particular, the computerprograms, when executed, enable the processor 204 to perform thefeatures of the present invention. Accordingly, such computer programsrepresent controllers of the computer system 200.

Detection Method

In a method in accordance with a preferred embodiment, the configurationinformation of a user's computer is determined and sent to a deliverymanagement server. The delivery management server then passes theconfiguration information to a transcoder that formats multi-mediacontent according to the configuration information. The formattedcontent can then be sent to the user.

An overall process in accordance with an embodiment of the invention isillustrated in FIG. 3A-3D. The process begins at step 305. In step 310,the user begins loading a web page of a content provider. As describedin Section 11, the web page contains server contact code which directsthe user's browser to the delivery management server. In an embodimentof the invention, this is accomplished in an HTML header of the contentprovider's web page. For example, the HTML header could contain thefollowing server contact code:

<SCRIPT SRC=“http://js.genericmedia.net/js”LANGUAGE=javascript></SRC>,where “js.genericmedia.net” represents the delivery management server.

In an embodiment of the invention, execution of the server contact codeis initiated by an action of the user, such as clicking on a control orlink in the content provider's web page, or by entering an explicitcommand. In an alternative embodiment, the server contact code isexecuted automatically after loading the web page. In step 320, theuser's browser fetches player detection code from the deliverymanagement server (“js” in the example above). In step 323, the mediaplayers that can be used by the user are determined. This step will bedescribed in greater detail below. In step 330, the identity of themedia players is recorded in one or more cookies in the user's computer.This step will also be described in greater detail below.

In conjunction with this step, a decision is made at the deliverymanagement server (step 331) as to whether the received configurationinformation, is sufficient to format the requested multi-media content.If cookies are received and verified as having valid settings, a minimalHTTP response is sent back, implying validity, if the receivedconfiguration information is sufficient to format the requestedmulti-media content, processing continues at step 335, described below.An additional decision point (similar to step 331) can be made betweenstep 320 and 325 in the method described and illustrated with referenceto FIG. 3A. That is, if sufficient information is received, playerdetection can be completely skipped in one embodiment. In anotherembodiment, some lightweight player detection even when sufficient infohas been received. In either case, a decision of what, if any, playerdetection code to send may be performed after step 320 when the clientrequests it from the server.

If js does not receive valid cookies (i.e., if configuration informationat the user is insufficient or nonexistent), the method continues atstep 332. In step 332 a preferences page is displayed for the user. Inan embodiment of the invention, this is accomplished by sending the usera segment of javascript that opens a new window which loads thepreferences page. The preferences page allows the user to deliberatelyindicate to the delivery management server the configuration orpreferences of the user with respect to the media player, and/or theuser's connection speed. In an embodiment of the invention, thepreferences page can also recommend to the user that a specific mediaplayer be chosen. Also, as will be described in greater detail below,the preferences page includes a mechanism through which the connectionspeed of the user's computer can be determined and relayed to thedelivery management server.

In step 333, the preferences provided by the user are received by theuser's computer. In step 334, the preferences are stored in cookies.Processing then continues at step 335. In step 335, the user requeststhe multi-media content, made available by the content provider througha web page, by making an HTTP request. Such a request can be made, forexample, by clicking on some region of the content provider's web page.As a part of this request, any cookies that contain configurationinformation are sent to the delivery management server. The cookiescould, for example, describe the media player type and version. Thecookies could also store the measured connection speed, as well as anypreferred connection speed that the user might have The user may, forexample, wish to use only a portion of the available bandwidth forstreaming. Here, the user would choose a slower speed than the maximumpermitted by the user's configuration. The process concludes at step370.

An example of an HTTP request (“GET”) is as follows. Existing cookies(gmPlayers, gmPlayerPref, and gmBitratePref) are sent to the deliverymanagement server as part of the GET command:

  GET/xc?p=keith&s=media/Trailer.mov&v=1 HTTP/1.1   Accept: image/gif,image/x xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint,application/vnd.ms-excel, application/ msword,*/*   Accept-Language:en-us   Accept-Encoding: gzip, deflate   User-Agent: Mozilla/4.0(compatible; MSIE 5.5; Windows NT 5.0)   Host: xc.genericmedia.net  Connection: Keep-Alive   Cookie:gmPlayers=v1% 2F % 2FQuickTime-4.12%2F % 2FReal-6.0.7.788% 2F % 2FWMP-6.4% 2F %2F; gm PlayerPref=real;gmBitratePref=300000

The server uses the URL information and cookie information to decide totranscode the movie “media/Trailer.mov” (in user Keith's account) to a300 kbps encoding suited for RealPlayer G2:

HTTP/1.1 200 OK Date: Mon, Jul. 16, 2001 23:52:00 GMT Server:Apache/1.3.14 (Unix) mod_perl/11.24 Connection: close Expires: Thu, Dec.1, 1994 16:00:00 GMT Pragma: no-cache, no-store, must-revalidate,no-transform Transfer-Encoding: chunked Content-Type:audio/x-pn-realaudio 41rtsp://64.124.76.136:554/cache/Mlk3JeFIY0209200d7dn-a/Trailer.rm 0

Note that a user may be configured with more than one media player. Ifso, it may be unclear how to format the content, i.e., which player tochoose. Moreover, the user may have a particular preference for oneplayer over another. The preferences page provides a way to resolvethese situations, by letting the user convey a player preference to thedelivery management server. In an embodiment of the invention, thepreferences page can convey a recommendation to the user as to whichmedia player might provide the best results.

There may also be cases where the above process fails to identify theuser's configuration with certainty. The player detection process maynot be able to unambiguously ascertain the user's media player, forexample, and the user might not know enough to answer the queries on thepreferences page. In such cases, the delivery management server may makeone or more inferences based on what is known about the user'sconfiguration. For example, if it is known that the user has a MACINTOSHplatform, it can generally be assumed that QUICKTIME is available on theplatform, since MACINTOSH computers are often equipped with QUICKTIME.Other such associations may also be used to infer configurationinformation that is otherwise unavailable. In an embodiment of theinvention, confirmation of such an inference can be had by solicitingthe user for confirmation, through the preferences page.

FIG. 3B is a flow chart illustrating server-side request processing inaccordance with an embodiment of the invention including receiving adelivery manager HTTP request 371. It is checked at step 372 whetherdelivery manager cookies have been received. If not, then at step 373, aHTTP response is sent containing code to send client to detection URL.If so, then at step 374, an empty HTTP response if returned.

FIG. 3C is a flow chart illustrating server-side request processing inaccordance with a preferred embodiment including receiving a detectionURL HTTP request 375. At step 376, HTTP headers are analyzed todetermine configuration information of the client. Among the informationdetermined is operating system, platform and HTTP client or user agent,as illustrated. As understood from further description herein, e.g.,with reference to FIGS. 7-9 and elsewhere, there are many features,characteristics and variances of client computers that may be determinedat step 376. In addition, particular items of information that aredesired to be received at the server may be indicated to the client asillustrated at FIG. 3D and described in more detail below.

To determine the bandwidth or connection speed of the client, aTimerStart code may be sent at step 377. A data block or timing block issent to the client for bandwidth measurement at step 378. A TimerStopcode is sent at step 379. In one embodiment, the bandwidth is calculatedfrom the amount of the data that is communicated during the time asdetermined from the difference between the TimerStop time and theTimerStart time, at step 380, and stored in a cookie. As described inmore detail below, instead of fixing the time and determining thebandwidth based upon how much data is sent during that time, the chunksize or timing block size may be fixed and the bandwidth determinedbased on how much time it takes to communicate it. Advantageously, thechunk size or timing block size may be selected so that the exerciselasts just above a minimum time needed to make a tolerably accuratebandwidth determination. At step 381, a client-side media playerdetection code is sent.

Detection Mechanism Details

In an exemplary usage scenario, users may be typically connecting from apersonal computer or a PDA (Palm, PocketPC). The connection may begenerally via HTTP from either a web browser or a media player that canmake HTTP requests.

A difficult aspect of this type of environment is that the client devicesoftware may typically not be written to or otherwise controlled, andinstead works within the constraints of existing clients. Morespecifically, there may be no way to a particular existing web browser(e.g., Internet Explorer, Netscape, Mozilla, etc.) and thusconfiguration detection algorithms must work within their support ofJavascript and work around bugs/quirks of individual browser versions.

Likewise, different media players support varying levels of version andinstalled-codec queries. In many cases (particularly for older players)there's no way to directly query whether a particular codec isinstalled. This is instead done indirectly relying on knownconfigurations. For example, if the media player is Windows MediaVersion 7.0, then it is understood that version shipped with WindowsMedia Video 7, Microsoft MPEG4v3, and Microsoft ISO-MPEG4v1 videocodecs.

In the case of PDA's, media player detection may be typically simplifiedby the fact that current media player support for PDA's is limited. Forexample, on PalmOS based PDA's, there may be only a single video playerthat is available and/or supported. On the PocketPC, as another example,Microsoft's Pocket Windows Media Player was the only available playerfor a tong-time. RealNetworks and PacketVideo have also introducedplayers for PDA's. With limited player choices, the detection logic canoften be simplified to 1:1 mappings between a given PDA and a (default)media player.

Bandwidth measurement is also not easy to estimate within theconstraints of HTTP and Javascript. Bandwidth measurement tools maytypically make their estimations by timing how long it takes a client toreceive a known quantity of data. Higher bandwidth estimation accuracymay be obtainable if the time measurement is restricted to just the timespent actually transmitting the data, and if the data-size trulyestimates the actual number of bites transmitted. Ideally, multiplemeasurements are taken to average out anomalies.

In an exemplary implementation, design requirements/constraints (fordetection mechanisms) may include:

Must be done from within a web page (in a web browser);

Code/scripting must only use languages which are already supported bythe client's existing web browser (e.g., Javascript, VBScript, HTML);

User must not need to install any downloaded modules/plugins;

Detection should be done as quickly as possible and as least invasivelyas possible (ideally, user shouldn't notice that detection code isrunning);

To do bandwidth measurement within the above constraints, measuringbandwidth via HTML and Javascript code may be one method. A small Javaapplet could allow for finer grained and more sophisticated measurementalgorithms, but may then require a downloaded applet and a Java runtimeenvironment, both of which may violate the design constraints.

Bandwidth measurement may be advantageously done by timing how long ittakes for a chunk of HTML data to be received by the client, “Random”ASCII data or other random data is preferably used to preventcompression by data-compressing modems, routers, and webservers (whichwould reduce the actual number of bits received, and thus affect thebandwidth calculation). In the interests of minimal user impact, thebandwidth measurement calculation is preferably only run once, andalternatively multiple times. The size of the data chunk may be selectedto be 20 kilobytes such as may balance the need for expedientmeasurement for modem users against the need for accurate measurementfor users on LAN connection speeds of around 300 kbps.

Again, due to the design constraints more advanced/accurate bandwidthmeasurement techniques may be undesirable. The measurements may be stillvulnerable to calculation corruption. Other applications or browserwindows may be sending data, thus slowing the transmission time, forexample. Also, intermediate routers may be buffering data andtransmitting it in large chunks. Moreover, data may still get compressedby intermediate routers/modems. The data may burst over the last networklink, e.g., from the firewall to the computer, or in the browser, e.g.,it may parse/execute Javascript in sections, any or all of which mayfalsely decrease the transmission time.

For clients that don't support Javascript, default detection results maybe used. Users could change their preferences at a later date byclicking a link to go to a settings/preferences changing web page.Default detection results may be advantageously customized for differentclients based on information gleaned from the HTTP Request headers(operating system, hardware platform, e.g.). In one embodiment, aMacintosh client might have as a default that QuickTime is installed,while a PocketPC client might have this default that Pocket WindowsMedia Player is installed. For connecting via a wireless modern carrier,the default bandwidth might be 56 kbps.

Persistent Data

A preferred implementation utilizes “cookies” for storing persistentdata between user sessions. Cookies are name-value pairs stored by anHTTP client which are associated with a domain. When the client makessubsequent HTTP Requests, it sends with the request cookies that areaffiliated with the HTTP server's domain. Cookies can be furtherspecified to expire (be deleted) after a certain date.

Separate cookies may be created/used in an exemplary implementation forstorage of things like measured bandwidth, detected media players (andtheir versions), user bitrate preference, user media player preferencefor streaming, and/or user media player preference for downloadedcontent. Each cookie may have its own expiration date which can beutilized to set the frequency at which portions of detected informationcould be considered stale and due for re-detection.

Specifically, things which consume a relatively large amount of time todetect (bandwidth and versions of installed media players) may be doneonce and then only re-detected periodically (or upon user request). Muchof the difficulty and complexity of typical configuration detectionimplementations is due to only being able to write/control theserver-side environment. Advantageously, client-side platforms,browsers, media players, scripting languages, bugs, etc., need notalways be worked within and around in accordance with a preferredembodiment, e.g., as being considered unchangeable, Per the designrequirements, upgrading/changing the client's installed software may benow allowed, although may alternatively be specifically not allowed.

Implementation Example

In an exemplary implementation in accordance with a preferredembodiment, many obstacles can be averted because there is much morefreedom in the client-side environment. Instead of devising indirectquerying methods to determine client software configurations orcapabilities, direct query support is advantageously designed in fromthe start. Likewise, client HTTP header values can be specified (and/ornew headers added) to provide detailed client information.

In this light, FIG. 3D is a flow chart illustrating further requestprocessing according to an embodiment of the invention. A modifiedinformation header instruction is sent at step 382. That is, a requestis sent to the client for different information than the client eitheralready has sent or is prepared to send based on a standard or previousrequest. A unique client ID is sent at step 383, so that the particularinformation requested and then received from the client is associatedwith that client. For example, different information may be requested ofother clients. Advantageously, different end user machines may haveunique ID codes for detection built in.

Client operations 384-386 illustrate an effect on client-side processingdue to server operations 382-383. At step 384, the client acknowledgesthe instruction received based on step 382 and appends client ID pointeraddress information to the requested header information based on step383. The client prepares modified header information at step 385depending the information requested in the instruction of step 382. Theclient sends at step 386 modified header information with ID uponfurther request. The subroutine ends at step 387. The modifiedinformation may include information that was not included in informationpreviously received or that the client understood was desired by theserver. This advantageously permits the server to get all of theinformation desired. The modified information may also excludeinformation that was included before or that the client would otherwisesend to the server. This advantageously can reduce the amount of databeing sent, particularly when some of the data is not desired forprocessing at the server or otherwise for transcoding and/or otherwiseproviding media transcoding services.

Adaptations of client hardware, client user interface version or otherclient configuration features may be included in the configurationinformation requested by the server and/or sent from the client. Themodified header information instruction may be prepared according tothis adaptation information. These adaptations, e.g., may be accordingto specific browser configurations at the client.

The design requirements of implementation architectures may be designedto provide more freedom for writing custom client software. Without theprogramming restraints of Javascript, e.g., custom extensions (perhapswritten in CC++) can implement more advanced or more accurate bandwidthmeasurement algorithms.

A form of persistent storage may be provided so that detectedinformation can be stored from one session to another. This canadvantageously reduce the time spent on bandwidth measurement.Alternatively, the bandwidth estimate may be measured and/or updatedconstantly, periodically or as requested based on timing/timestamps ofdata being sent from the server to the client. Within a given session,e.g., detection information may be kept in memory so that it can be sentby the client with requests to the server.

Implementation Example Details

As mentioned previously, direct reporting of client capabilities isgenerally easier and more efficient than indirect querying. For mediaplayer detection, the client may advantageously have a way ofquickly/easily knowing what media players are installed on a client.According to one embodiment, hooks are provided into the operatingsystem (or software installation manager) so that detection software candirectly query for what media player software is installed, what versionit is, what version of codecs are installed, and/or for otherconfiguration information. If the implementation is done such that onlyone media player is installed and/or that additional installationsaren't available, or that the detection management software is integralto the media player, it might be advantageous to have the media playersoftware directly report this information instead.

On the server-side, direct correlations may be made about a client'sactual media player capabilities from the version information reported.For example, it might be known that version 1.0.4 of the V XYZ videocodec is capable of decoding a video compressed with the XYZ algorithm,but that the decoder requires the video frame/size dimensions to bemultiples of 8 pixels. Another example might be that if the clientreports it has audio codec A ABC version 1.1 and audio codec A DEFversion 3.0 that the server must not send data encoded with any otheraudio codec, and that the compression algorithm used must be decodableby one of the client's audio codecs.

All bandwidth measurement algorithms fundamentally boil down tomeasuring how long it takes to receive a known-size chunk of data or howmuch data is communicated in a predetermined period of time.Advantageously, an algorithm is described in more detail below withreference to FIG. 5B including sending one or more of multiple chunks ofdata such that the chunk-size or timing block size may be varied orselected according to a current approximated bandwidth.

Detection information may be used on the server side to decide on atranscoded bitrate and media player format/version. It is generallyinefficient and resource intensive to provide transcodes in all possiblecombinations of bandwidths and codec. The codecs used may be limited,e.g., to the most commonly installed and the bitrates encoded may belimited to ones that supported the most common target audiences, e.g.,20 kbps for 28.8 modem, 34 kbps for 56 k modems, 90 kbps for ISDN, 300kbps for DSL, and 500 kbps for cable-modem.

Referring back to Step 325 of FIG. 3A, the step of performing playerdetection, is described in greater detail in FIG. 4A. This processbegins at step 405. In step 410, a determination is made as to whatbrowser the user has. Typically, the user's browser will be either aversion of NETSCAPE NAVIGATOR, or a version of INTERNET EXPLORER (IE).If the user has NETSCAPE NAVIGATOR, then the process continues at step411. In step 411, a string search for a given media player is performedthrough the resident mimetype array and plugin array. The mimetype arrayis a mapping of what application to load upon receiving a response witha given mimetype. Any given media player typically has its own mimetype.The plugin array is a listing of all browser plugins that have beeninstalled; typically, each has registered a corresponding mimetype. As aresult, these arrays will typically contain character strings thatindicate the media player(s) resident on the user's computer. QUICKTIMEis indicated by the string “QuickTime” for example, and WINDOWSMEDIAPLAYER is indicated by the string “video/x-msvideo”.

If in step 413 the string search is successful, then the player isdetermined to be present in step 415. Otherwise, processing continues atstep 416. In step 416 a determination is made as to whether anothermedia player is to be sought. If so, processing returns to step 411, anda string search is conducted for another media player. In theillustrated embodiment, therefore, multiple string searches willgenerally be performed, although the invention can be implemented toperform a single search. The process concludes at step 417.

Note that different versions of a given player may be registered withthe browser using slightly different names or properties. Detection ofthese distinctions by string searches can provide information as tospecific versions, in an embodiment of the invention, the stringsearches are implemented using javascript.

If, in step 410, it is determined that the user's browser is INTERNETEXPLORER, then the process continues at step 420. Here, the browser isasked to instantiate an object for a given media player and version. Inan embodiment of the invention, this instantiation is done usingVbscript. Creation of a REALPLAYER version 5 object, for example, wouldbe attempted with the statement

CreateObject(“RealPlayer.RealPlayer™ ActiveX Control (32-bit)”.

If, in step 425, this instantiation, is permitted, this implies that themedia player is in fact present on the user's computer, as shown in step430. The process then continues at step 440. It, in step 425,instantiation of the given media player object is not permitted, then itcan be assumed that the media player is not resident at the user'scomputer. In step 440, a determination is made as to whether thepresence of any other media player should be ascertained. If so, theprocess returns to step 420 and another attempt will be made, this timeto instantiate an object for a different media player. If, in step 440,a determination is made that no other media player will be sought, thenthe process concludes at step 417. Note that differences betweenplayers, especially differences between versions of a player, can bedetected by corresponding differences in how player objects areinstantiated in step 420. Also, for player objects that support versionqueries (e.g., QUICKTIME and REALPLAYER), the player can be askeddirectly about its version.

Windows Media Player Detection

FIG. 4B is a flow chart illustrating client-side windows media player(WMP) detection in accordance with an exemplary embodiment of theinvention. At step 441, it is checked whether WMP is available on thisclient's OS/platform. If not, then WMP version is set to no at step 451and the method moves on to RealPlayer detection in accordance with thisexample. If so, then at step 442, it is checked whether ActiveX isavailable on the client browser. If yes, then at step 443 it is checkedwhether ClassID for WMP 7.1 or WMP 8 may be created. If yes, then atstep 444, WMP version is set to version 7.1 and the process moves toRealPlayer detection according to FIG. 4C is this example. If it isdetermined at step 443 that a ClassID for either WMP 7.1 or WMP 8 cannotbe created, then at step 445, it is checked whether ClassID for WMP 7may be created. If so, then WMP version is set to WMP 7 and the processmoves to RealPlayer detection. If at step 445, it is determined thatClassID for WMP 7 cannot be created, then at step 447 is it checkedwhether that for WMP 6.4 may be created, and if so, WMP version is setto 6.4 and if not, the process moves to step 449. There it is checkedwhether a WMP object may be created, and if so, WMP version is set toyes, and if not, then WMP version is set to no, and either way, theprocess moves to RealPlayer detection as illustrated at FIG. 4C.

If the result of the checking at step 442 whether ActiveX is availableon the client browser is no, then the process moves to step 452. It ischecked at step 452 whether mimetype application/x-ms-wmd is registeredby a plugin. If so, then WMP version is set to version 7 ending the WMPdetection procedure. If not, then at step 453, is it checked whethermimetype application/x-ms-wmv is registered to a plugin. If so, then WMPversion is set to version 6.4 ending the sub-routine. If not, then atstep 454, it is checked whether mimetype application/x-msplayer2 isregistered to a plugin. If so, then WMP version is set to yes, and ifnot, then EMP version is set to no, and either way, the process moves toRealPlayer detection,

Realplayer Detection

FIG. 4C is a flow chart illustrating client-side RealPlayer (Real)detection in accordance with an exemplary embodiment of the invention.At step 455, it is checked whether Real is available on this client'sOS/platform. If not, then Realversion is set to no ending thesub-routine and moving the process on to Quicklime detection. If so,then at step 456, it is checked whether ActiveX is available on thisbrowser. If yes, then at step 457 it is checked whether a RealPlayer G2object may be created. If so, then Realversion is set toRealPlayerG2Object,GetVersioninfo( ) and the process moves to QuickTimedetection as illustrated at FIG. 4D, if not, then at step 459, it ischecked whether a RealPlayer object may be created, if yes, thenRealversion is set to version 5 ending the sub-routine, and if no, thenthe process moves to step 461 where it is checked whether a Real Videoobject can be created. If yes, the Realversion is set to version 4, andif not then Realversion is set to no and either way, the sub-routine isended.

If at step 456, it is determined that ActiveX is not available on thisbrowser, then the sub-routine moves to step 464, as illustrated at FIG.4C, where it is checked whether mimetype audio/x-pn-realaudio-plugin isregistered by a plugin. At step 465, Realversion is set to yes. Then, atstep 466, it is checked whether there is a plugin name containing“RealOne”. If so, then Realversion is set to One at step 467 ending thesub-routine. If not, then at step 468, it is checked whether there is aplugin name containing “RealPlayerG2”, and if so, then Realversion isset to G2 ending the sub-routine. If not, then at step 470, it ischecked whether there is a plugin name containing “RealPlayer”. If so,then Realversion is set to version 5, and if not, then at step 471, itis checked whether there is a plugin name containing “Realvideo”. If so,then Realversion is set to version 4, and if not, then Realversion isset to no, and either way, the process moves to FIG. 4D and QuickTimedetection.

Quicktime Player Detection

FIG. 4D is a flow chart illustrating client-side QuickTime (QT)detection in accordance with an exemplary embodiment of the invention.At step 472, it is checked whether QT is available on this OS/platform.If no, then QTversion is set to no ending the sub-routine. If yes, thenat step 473, it is checked whether Active is available on this browser.If yes, then at step 474, it is checked whether a QuickTimeCheek objectcan be created. If not, then QT version is set to no, and if so, thenthe sub-routine moves to step 475. There it is checked whether QuickTimeis available by using, CallQuickTimeCheckObjectVersion.IsQuickTimeAvaiiable( ). If the result ofthe checking at step 475 is no, then Qtversion is set to no and if theresult of step 475 is yes, then QTversion is set toQuickTimeCheckObject.QuickTimeVersion, and either way, the sub-routineis ended upon saving of the detection results at step 482.

If at step 473, it is determined that ActiveX is not available on thisbrowser, then at step 478, it is checked whether mimetypevideo/quicktime is registered by a plugin. If not, the QTversion is setto no, and if so, then QTversion is set to yes at step 479. Then, atstep 480, it is checked whether there is a plugin name containing“QuickTime Plug-in”. If no, then the sub-routine is ended and detectionresults saved at step 482. If so, then QTversion is set to QuickTimePlug-in version, and the results are then saved at step 482, ending theprocess group illustrated at FIGS. 4B-4D.

Referring to Step 355 of FIG. 3A, the step of presenting a preferencespage to the user, is illustrated in greater detail in FIG. 5A accordingto an embodiment of the invention. The process begins at step 505. Instep 510, the preferences page is loaded from the delivery managementserver. In step 515, the transfer of a block of data of known size,stored within the preferences page, begins. The transfer of this blockis timed to determine the user's connection speed. This block is denotedhereinafter as a timing block. In an embodiment of the invention, thetiming block is included in the preferences page as an HTML comment. Asa result the browser ignores the timing block for processing purposes.

At the same time the transfer of the timing block begins, the browsernotes the time at which the transferring of the timing block starts. Instep 520, the transfer of the timing block concludes, and the time atwhich the transfer concludes is also noted by the browser, In step 530,a calculation is made as to the connection speed, i.e., data transferrate, based on the time required to transfer the timing block and on itsknown size. In step 535, loading of the preferences page concludes andthe possible configurations that the user might have are displayed forthe user. In step 540, the user's input with regards to theconfiguration is received. The process concludes at step 545.

The preferences page can also be displayed at times other than what isdescribed above with respect to FIG. 3A. In an embodiment of theinvention, the user is given a link in the content provider's web pagethrough which the user can access the preferences page whenever desired.This allows the user to change the stated preferences at will. Inanother embodiment of the invention, the preferences page is displayedto the user at regular intervals, e.g., every six months. This allowsthe user to make periodic updates of the configuration information.

With respect to the setting of cookies, when a browser makes a requestto a server, the browser only sends up cookies that are associated withthe server's domain. A cookie can be associated with a new domain in oneof two ways:

1) a Set-Cookie: header is received from a server within the new domain,or

2) the cookie is set via javascript by a page that was loaded from aserver in the new domain.

Since the player detection code is not always being run from a deliverymanagement server page (e.g., the case where the player detection isloaded as part of the header of a content provider's web page), a way toset the cookies is needed. The goal is a third party cookie, whereby acookie that would otherwise be set to the original domain (the contentprovider's domain) is set instead to the delivery management server'sdomain. In an embodiment of the invention, this can be done by making adummy image( ) request from within javascript. Given a request that theimage be loaded from the delivery management server's domain, thedelivery management server can reply by sending back a Set-Cookie:header.

This can be applied in steps 330 and 334 above. For example, a URL maybe built at the user's computer directed to a cookie set script at thedelivery management server. Next, a dummy image object may be created atthe user's computer. This object serves no purpose except to allow adummy image request to be made, from within javascript, to the domain ofthe delivery management server. Then, the browser makes an HTTP request,asking that a dummy image be loaded from the domain of the deliverymanagement server; this request incorporates a request for the cookieset script. The delivery management server responds by associating thecookies with the server (i.e., sending back a Set-Cookie: header). Thiswill allow the cookies to be sent to the delivery management server,even though their presence at the user's computer may have originallybeen determined by the content provider or some other domain. Theconfiguration information is stored in the cookies.

An example of such an exchange between a user and a delivery managementserver is illustrated below:

  GET/ssp/cookieset?gmPlayerPref=real HTTP/1.1   Accept: image/gif,image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint,application/ vnd.ms-excel, application/msword,*/*   Accept-Language:en-us   Accept-Encoding: gzip, deflate   User-Agent: Mozilla/4.0(compatible; MSIE 5.5; Windows NT 5.0)   Host: js.genericmedia.net  Connection: Keep-Alive   Cookie:gmPlayers=v1% 2F % 2FQuickTime-4.12%2F % 2FReal-6.0.7.788% 2F % 2FWM P-6.4% 2F % 2F;gmPlayerPref=wmf;gmBitratePref=300000   The server then responds:   HTTP/1.1 200 OK  Date: Tue, Jun. 12, 2001 20:08:29 GMT   Server: Apache/I.3.14 (Unix)mod_perl/1.24   Set-Cookie: gmPlayers=v1% 2F % 2FQuickTime-4.12% 2F %2FReal-6.0.7.788% 2F % 2 FWMP-6.4% 2F % 2F;domain= .genericmedia.net;path=/; expires=Mon, Sep. 10, 2001 20:08:29 GMT   P3P: CP=“IND OUR PREUNI ONL COM”   Set-Cookie: gmPlayerPref=real; domain=.genericmedianet;path=/;expires=Mon, Sep. 10, 2001 20:08:29 GMT   Connection: close  Cache-Control: no-cache, max-age=1   Transfer-Encoding: chunked  Content-Type: text/html

FIG. 5B is a flow chart generally illustrating a bandwidth detectionmethod according to an embodiment of the invention. In this embodiment,a sub-routine is started at step 550 and proceeds at step 552 to fetchestimated bandwidth information, e.g., at determined, from a previousbandwidth detection or otherwise. At step 554, an estimated time toretrieve data is determined for determining a connection speed withadequate resolution, i.e., using the estimated bandwidth information.Here, the reason for this is that we want the timing block or chunk-sizeto be selected based on the results of this step, and we want thisestimated time to be not shorter than and not much longer than a minimumtime within which bandwidth information may be determined within atolerable resolution. For example, if the estimated time is too long fora client having a slow connection speed, then the bandwidth measurementwill likely involve an annoying and unneeded delay for the user.However, if the estimated time is too short, e.g., for a client having avery fast connection speed, then the error in the determination will betoo great or outside a tolerable margin of error.

Once that estimated time is determined, then the chunk-size or timingblock size that will take the estimated time to communicate isdetermined at step 556. In accordance with a preferred embodiment,random data such as random ascii data is used in the timing block orchunk, so that modems will not compress the data and make thecommunication time drastically shorter than the estimated time andleaving the result outside the resolution tolerance,

Once the timing block size or chunk-size is determined that will takeapproximately the estimated time, then a timing block or data chunk ofthat determined size is communicated to the client at step 558. Theactual time it takes to communicate the timing block is measured. Thebandwidth is then determined at step 560 based on the size of the datachunk or timing block sent in step 558, and on the measured retrievaltime by the client. The sub-routine illustrated at FIG. 5B is ended atstep 562.

Accessing Media Content According to Embodiments

As described herein, systems and methods in accordance with preferredembodiments perform the transcoding of media content on demand, inresponse to a viewer's request to access media content. Additionally,preferred embodiments essentially perform the transcoding of mediacontent in “real-time” after the publication of the media content, aspart of the media content delivery process, in particular embodiments,the delay between the submission of a request to view media content tothe media transcoding engine (see U.S. Pat. No. 6,407,680 and U.S.patent application Ser. No. 10/644,602, which are incorporated byreference) and the delivery of the media content to a viewer client willbe approximately thirty seconds or less. However, the invention is notlimited to a specific delivery time and can encompass a variety ofdelivery times greater than or less than thirty seconds.

FIGS. 6A-6C depict a flowchart 1500 of a method by which media contentis accessed by a viewer according to embodiments of the presentinvention. The invention, however, is not limited to the descriptionprovided by the flowchart 1500. Rather, it will be apparent to personsskilled in the art from the teachings herein that other functional flowsare within the scope and the spirit of the present invention.

In step 1502 of FIG. 6A, the viewer sends a request to access mediacontent via the viewer client to the viewer Web server interface withinthe media transcoding engine. In embodiments, the request is an HTTPrequest generated by the viewer client when the viewer clicks on a URLon the content provider's web-site. As discussed above, the URL link,which may be provided by the media transcoding engine to the contentprovider during the media content publishing process, contains addressinformation and source information that points the viewer client to themedia transcoding engine and provides information to the mediatranscoding engine about the source of the requested media content.After the viewer Web server interface receives the request, it forwardsit to a task manager (again see the U.S. Pat. No. 6,407,680 and Ser. No.10/644,602 application, incorporated by reference).

In step 1504, the task manager parses the request to determine if thenecessary request information is included in order to service therequest. In embodiments of the invention where the request comprises anHTTP request, the task manager parses the header of the HTTP request todetermine if the necessary information is included in order to servicethe request. In embodiments, the necessary information includes at leasta source location, a source type, a destination location, and adestination type. The source type and destination type are each definedby at least one publishing variable. In embodiments, publishingvariables for media content can include, but are not limited to the fileformat, bit rate, communication protocol(s), physical medium,compression algorithm, digital rights management information, or anycombination thereof. In one embodiment, the information required forservicing the request includes at least a source location, a sourceformat, a source bit-rate, a destination location, a destination format,and a destination bit rate.

If the task manager determines that the request information is notcomplete, the task manager will fetch the necessary information as shownin steps 1506 and 1508. For example, if the source type or sourcelocation is not included in the request and the requested media contentis stored within the media transcoding engine, the task manager canconsult a database to find the necessary source information.Alternately, if the media content is stored externally with respect tothe media transcoding engine, the task manager can perform a networkrequest to fetch the necessary information from the content provider'sweb-site. For example, the task manager can perform an HTTP request, anRTSP request, or a request using any other standard network applicationprotocol. Additionally, if the destination type is not available, thetask manager can fetch the needed information by querying the viewerclient. As discussed above, in embodiments, the optimal destination typefor the destination location may be stored as a “cookie” on the viewerclient, which may be accessed by the task manager.

At step 1510, once the task manager has the necessary information toservice the request, it then determines what tasks need to be executedin order to deliver the requested media content. The tasks include allthe steps necessary to deliver the requested media content, and mayinclude fetching the requested media content, transcoding the requestedmedia content from the source type into the destination type, andstreaming the transcoded media content to the viewer client. Once thetask manager has determined what tasks need to be executed, it theninterfaces with a resource manager (again see the U.S. Pat. No.6,407,680 and Ser. No. 10/644,602 application, incorporated byreference) and instructs the resource manager to execute the requiredtasks.

The resource manager receives the instruction to execute the requiredtasks from the task manager and, at step 1512, assigns each task to oneor more machines within the machine farm. The resource manager isprogrammed to achieve an efficient execution of tasks by the availableresources. In embodiments, the allocation of resources to a given taskby the resource manager is determined based on a variety of factorsincluding, but not limited to, which machines support the necessaryutilities for performing the required task, which machines haveavailable resources (for example, available CPU), and which machines cancoordinate with each other to carry out the task when coordination isrequired for execution. The resource manager can also be programmed todistribute tasks based on a variety of other criteria including theavoidance of network congestion. For example, the resource manager maybe programmed to assign decompression and compression tasks to the samemachine in order to avoid the network congestion that may result fromtransmitting uncompressed data from one machine to another within theinternal network of the media transcoding engine.

In accordance with a preferred embodiment, the resource manager overseestasks after they are assigned to make sure that they are properlyexecuted. The resource manager oversees the execution of assigned tasksby maintaining a list of all assigned tasks in the database andperiodically communicating with the slave monitor of each machinerunning a given task in order to determine the status of the task.

In embodiments, the resource manager periodically polls the slavemonitor of the machine to which the task has been assigned to determinethe status of the task. In alternate embodiments, the slave monitoritself sends periodic status messages to the resource manager, informingit of the status of an assigned task. The resource manager storesinformation that it receives from the slave monitors about the status ofeach task and each machine in the database in order to assist in itsfunction of assigning and monitoring necessary tasks.

In an alternate embodiment, the slave monitors only initiate tasksreceived from the resource manager, and the tasks themselves reportdirectly to the resource manager rather than to the slave monitors.

The resource manager monitors each assigned task in accordance with afault tolerance routine that permits the resource manager to determinewhen a task has failed and to execute the necessary steps for correctingthe problem and ensuring the delivery of the requested media content.For example, if a machine to which a task has been assigned does notrespond to a status query for a predetermined period of time, theresource manager can be programmed to reassign the task to a differentmachine and re-boot the machine that is not responding. Additionally,where the failure of a task also results in the failure of a chain ofdistributed dependent tasks, the resource manager can be programmed toshut down all the dependent tasks and re-assign the entire set of tasksin order to ensure the delivery of the requested media content. Theseexamples are not limiting, and other fault tolerance schemes will beapparent to one of ordinary skill in the relevant art based on theteachings contained herein, and the invention is directed to such otherfault tolerance schemes.

In a further embodiment, individual tasks are each assigned a priority.The resource manager monitors new tasks and when the priority of anexisting task is lower than that of a new task that needs to beassigned, the resource manager will instruct the existing task to killitself to accommodate the new higher-priority task. Alternately, theslave monitor can kill the existing task. An example of a low prioritytask includes the transcoding of media content for a viewer after theviewer has stopped viewing the requested content.

At step 1514, after all the tasks have been assigned, the task managerconstructs a reply to the initial request to access media contentreceived from the viewer client. The reply serves to redirect the viewerclient to a streaming server or proxy server from which the requestedmedia content will ultimately be received by the viewer client. Inembodiments, the reply comprises an HTTP reply.

At step 1532, a determination is made whether auto source type detectionin accordance with a preferred embodiment is turned on. The system maybe permanently set to automatic source type detection on or to automaticsource type detection off or it may be selectively toggled. If theautomatic source type detection is permanently on or off, then thedetermination is not necessary and the method can move to thecorresponding step 1534 or 1536. In the method illustrated at FIG. 6B,after the determination is made, then the method move to the nextcorresponding step. That is, if automatic source type detection isturned on then at step 1534, source type information is automaticallyfetched from source server or client. An advantage is that this isquicker and simpler for the user. Alternatively, if automatic sourcetype detection is turned off, then at step 1536, input is requestedthrough a source user interface from a user who is demanding thecontent. An advantage is that a user with multiple source types for thecontent can choose between them, or if the source has a firewall suchthat the source type cannot be readily detected with user input.

At step 1538, a determination is made whether auto destination typedetection in accordance with a preferred embodiment is turned on. Thesystem may be permanently set to automatic destination type detection onor to automatic destination type detection off or it may be selectivelytoggled. If the automatic destination type detection is permanently onor off, then the determination is not necessary and the method can moveto the corresponding step 1540 or 1542. In the method illustrated atFIG. 6B, after the determination is made, then the method move to thenext corresponding step. That is, if automatic destination typedetection is turned on, then at step 1540, destination type informationis automatically fetched from destination server or client. An advantageis that this is quicker and simpler for the user. Alternatively, ifautomatic destination type detection is turned off, then at step 1542,input is requested through a destination user interface from a user whois demanding the content. An advantage is that a user with multipledestination types for the content can choose between them, or if thedestination has a firewall such that the destination type cannot bereadily detected with user input.

Further criteria independent of destination type may be detected andapplied based upon designated rules, e.g., as set out by the publisherof the media content or otherwise based upon a business rule. Forexample, bandwidth criteria may be based upon a customer's contract, ora trailer or a clip or both may be inserted with the transcoded mediacontent upon request by a publisher.

At steps 1516-1526 of FIG. 6C, the machines within the machine farmperform the steps necessary to deliver the requested media content inaccordance with the assigned tasks received from the resource manager.In embodiments of the present invention, the delivery of media contentis a pipelined process in which the fetching, transcoding and streamingof different portions of the same media content stream may occursimultaneously. The resource manager arranges for the pipelining ofthese steps through resource allocation within the media transcodingengine. The pipelining of these steps results in a faster delivery timefor requested media by the media transcoding engine.

As shown at step 1516, if the requested media content already resides ina transcoded cache transcoded into the appropriate destination type(e.g., the appropriate destination format and bit-rate or otherappropriate publishing variables), then the delivery of content isachieved by streaming servers at step 1524, which stream the transcodedmedia content to the viewer client.

If however, the requested media content does not reside in thetranscoded cache transcoded into the appropriate destination type, thenone or more transmitter servers within the machine farm begins fetchingthe requested media content as a data stream from the source location asshown at step 1518. As discussed above in regard to FIGS. 3A-3B and4A-4D, in embodiments of the invention, the requested media content caninitially either reside within a master archive within the mediatranscoding engine, in an archive external to the media transcodingengine, or be received as a streaming feed directly from the contentprovider client. Where the requested media content resides within themaster archive, one of the transmitter servers fetches the requestedmedia content over the internal network of the media transcoding engine.

Where the requested media content resides in an archive outside of themedia transcoding engine, one of the transmitter servers uses the accessinformation provided during the publishing process to fetch therequested media content. In embodiments, after the transmitter serveruses the access information to fetch the requested media content, therequested media content may be temporarily cached in the master archive,permitting expedited access to the media content when subsequentrequests for the same media content are received by the mediatranscoding engine.

Where the requested media content is a streaming feed directly from thecontent provider client, one of the transmitter servers fetches thestreaming data from the content provider Web server interface. Becauseembodiments of the present invention do not fetch and transcode thestreaming data until it is actually requested by a viewer, unnecessarytranscoding of media content is thereby avoided.

As shown in step 1520, after the transmitter server begins fetching therequested media content, if the source type is the same as thedestination type (e.g., the source format and hit rate is the same asthe destination format and bit-rate), then no transcoding is necessaryand the media content is transmitted to the streaming servers as soon itis fetched. The streaming servers then stream the content to the viewerclient at step 1524, as described below. However, if the source type isnot the same as the destination type, then one of the transcodingservers within the machine farm will transcode the media content fromthe source type to the destination type as shown in step 1522. Inaccordance with the discussion in regard to step 1512, above, theresource manager assigns the transcoding task to a transcoder serverthat runs the necessary transcoder software for performing theappropriate conversion of publishing variables. In embodiments, thetranscoding is carried out using one of a variety of well-known methodsand for converting media content of one type to another, includingconventional codec routines for transcoding media content. Furtherdescription of transcoding operation and examples are provided below. Inembodiments, after the transcoding is complete, a copy of the transcodedmedia content is temporarily stored in the transcoded cache, permittingexpedited delivery of the media content when subsequent requests for thesame media content transcoded into the same destination type arereceived by the media transcoding engine.

In step 1524, one of the streaming servers streams the media content inthe appropriate destination type to the viewer client as soon as it isreceived from either a transcoder, a transmitter or the transcodedcache. In embodiments, the transcoded media content is streamed to theviewer client via an optional proxy server. In further embodiments,either the streaming server or the optional proxy server keep usagestatistics pertaining to the media content being delivered as well asthe destination types in which the media content is being delivered thatare used by the resource manager for cache management purposes.

In embodiments, the protocol used for streaming media to the viewerclient and for streaming data between the transmitter servers,transcoder servers and the streaming servers is a standard protocol forstreaming media, such as RTSP. Alternately, a proprietary protocoldefined over standard network protocols like TCP/UDP can be used. Infurther embodiments, different protocols may be used to accommodatedifferent network infrastructure needs. For example, protocols may beimplemented that dynamically change according to network trafficconditions. However, these examples are illustrative. The presentinvention is not intended to be limited to a specific communicationprotocol or application, and other proprietary or non-proprietarynetwork communication protocols and applications can be used.

At step 1526, the viewer client receives the streaming media contentfrom either the streaming server or the proxy server. At this point, theviewer client plays the media content in accordance with the destinationtype associated with the media player resident on the viewer client. Inalternate embodiments of the present invention, the media content may bereceived and stored as a downloaded file on the viewer client forplaying at a later time, or for transfer to an alternate media playingdevice. After step 1526, the flowchart 1500 ends.

Media Content Examples

As described in the U.S. Pat. No. 6,407,680, e.g., a media transcodingengine may include one or more transcoders. Transcoders convert certaintypes of media content (referred to herein as a source type) to anothertype of media content (referred to herein as a destination type).Transcoding can involve a number of different conversion operations. Theparticular conversion operations used depend upon the media content andassociated publishing variables being converted. This is why theefficient detection of the configuration information of a client, whichmay be a destination, is advantageous. Publishing variables as usedherein refer to different characteristics of media content.

According to a preferred embodiment, media content is digital data beingpublished over a network, in this case, publication refers to digitaldata which has been formatted for delivery over a network and forviewing by a destination media player. Publishing variables for mediacontent can include, but are not limited to, the file format, bit rate,communication protocol(s), physical medium, compression algorithm,and/or digital rights management information.

The digital data can be any type of file format including but notlimited to container formats, bitmap formats, video formats, audioformats, vector formats, metallic formats, scene formats, animationformats, multimedia formats, hybrid formats, hypertext and hypermediaformats, three-dimensional data (3D) formats, virtual reality modelinglanguage (VRML) formats, font formats (bitmap fonts, stroke fonts,spline-based outline fonts), page description language (PDL) formats,and any other type of graphics file format or other file format, Table 1lists examples of such file formats that can be used in embodiments ofthe present invention:

TABLE 1 Example File Formats Format Type ADOBE ILLUSTRATOR MetafileADOBE PHOTOSHOP Bitmap ATARI ST GRAPHICS FORMATS Bitmap and AnimationAUTOCAD DXF Vector AUTODESK 3D STUDIO Scene Description BDF BitmapBRL-CAD Other BUFR Other CALS RASTER Bitmap CGM Metafile CMU FORMATSMultimedia DKB Scene Description DORE RASTER FILE FORMAT Bitmap DPXBitmap DR. HALO Bitmap DVM MOVIE Animation ENCAPSULATED POSTSCRIPTMetafile (page description language) FACESAVER Bitmap FAX FORMATS BitmapFITS Other FLI Animation GEM RASTER Bitmap GEM VDI Metafile GIF BitmapGRASP Animation GRIB Other HARVARD GRAPHICS Metafile HIERARCHICAL DATAFORMAT Metafile IFF Bitmap IGES Other INSET PIX Bitmap INTEL DVIMultimedia JPEG FILE INTERCHANGE Bitmap FORMAT KODAK PHOTO CD BitmapKODAK YCC Bitmap LOTUS DIF Vector LOTUS PIC Vector LUMENA PAINT BitmapMACINTOSH PAINT Bitmap MACINTOSH PICT Metafile MICROSOFT PAINT BitmapMICROSOFT RIFF Multimedia MICROSOFT RTF Metafile MICROSOFT SYLK VectorMICROSOFT WINDOWS Bitmap BITMAP MICROSOFT WINDOWS Metafile METAFILE MIFFBitmap MPEG Other MTV Scene Description NAPLPS Metafile NFF SceneDescription OFF Scene Description OS/2 BITMAP Bitmap P3D SceneDescription PBM., PGM., PNM., and PPM. Bitmap PCX Bitmap PDS OtherPICTOR PC PAINT Bitmap PIXAR RIB Scene Description PLOT-10 Vector PNGBitmap POV Vector PRESENTATION MANAGER Metafile METAFILE PRT SceneDescription QRT Scene Description QUICK TIME Other RADIANCE SceneDescription RAYSHADE Scene Description RIX Bitmap RTRACE SceneDescription SAF Bitmap and other SENSE8 NFF Scene Description SGI IMAGEFILE FORMAT Bitmap SGI INVENTOR Scene Description SGI YAODL SceneDescription SGO Vector SPIFF Bitmap SUN ICON Bitmap SUN RASTER BitmapTDDD Vector and Animation TGA Bitmap TIFF Bitmap TTDDD Vector andAnimation URAY Scene Description UTAH RLE Bitmap VICAR2 Bitmap VIFFBitmap VIS-5D Vector VIVID AND BOB Scene Description WAVEFRONT OBJVector WAVEFRONT RLA Bitmap WORDPERFECT GRAPHICS Metafile METAFILE XBMBitmap XPM Bitmap XWD Bitmap ZBR MetafileSee, Murray and vanRyper, pp. 12-26. These examples are illustrative andnot intended to limit the present invention. Other file formats (nowknown or developed in the future) can be used as would be apparent to aperson skilled in the art given this description.

Even within the same file format, digital data can be compressedaccording to different compression algorithms. In a QUICK TIME formattedfile, for example, video can be compressed in accordance with H.263,CINEPAK, JPEG, QT ANIMATION, or QT VIDEO standards. As a furtherexample, in a WINDOWS MEDIA ASP formatted file, audio can be compressedin accordance with the MICROSOFT AUDIO FORMAT, ACELP, VOXWARE, or MP3standards. Compression algorithm choices can be made based onoptimization according to bit-rate choices, or according to the natureof the content. For example, video files in which little motion occurs(“talking heads”) and video files in which there is a substantial amountof motion (“high-motion” video) may each be more efficiently compressedusing different compression algorithms.

Within any one compression algorithm, there can be further variations.For example, files compressed according to the PEG standard can beeither YUV-based or RGB-based.

With respect to the digital rights management system of the preferredembodiment, a media player on a client computer detected in accordancewith an aspect of the invention determines the DRM information type, orusage rule type, which it cm handle. For example, Windows Media Playercan interpret and/or handle usage rules provided by Microsoft WindowsMedia DRM system, but generally cannot interpret and/or handle thoseprovided by Real's Helix DRM system. Moreover, RealOne player caninterpret and/or handle those provided by Real's Helix DRM system, butcannot interpret and/or handle those provided by Microsoft Windows MediaDRM system. That is, a media player type generally has a one-to-onecorrespondence to DRM type that it can interpret.

In addition, DRM information or usage rule information may be describedby XrML, XML or the like including tags and their values. DRMinformation or usage rule information may also be attached to content.Otherwise, it may be separated physically from content and is associatedlogically to content through content ID or the like. DRM information orusage rule information may also define how and/or when a user can usethe associated content.

In accordance with an aspect of this invention, the server system canautomatically detect media player type on a client computer, determine aDRM type on the client computer based on media player type, andautomatically transcode DRM information or usage rule information to beable to interpret and/or handle it on the client computer. As describedat U.S. Pat. No. 6,407,680, DRM information may be transcoded fromsource type (e.g., MSFT Windows Media DRM) to destination type (e.g.,Real Helix).

According to this aspect of the invention, then, a method for remotelydetermining the configuration of a computer of a multimedia content useris provided. The advantageous method includes sending player detectioncode to the user's computer, receiving configuration informationregarding the user's computer, and determining a type of digital rightsmanagement information on the user's computer based on the receivedconfiguration information.

In addition to the publishing variables set forth above, there are alsopublishing variables unique to video data and audio data. Publishingvariables for video data include the width and height of the video imagein pixels as well as the frame rate of the video. Depending on thebit-rate requirements and the nature of the data, different settings maybe necessary in order to ensure the best picture quality. For example,some video may be better viewed at 1.5 frames per second at 160×120pixels, while some others may be better viewed at 5 frames per second at320×240 pixels, even at the same bit-rate. Where the bit-rate is 56Kbps, picture quality becomes very limited, and it is almost neveroptimal to deliver video in 640×480 pixel resolution. Yet anotherpublishing variable for video data is the number of bits per component.

Publishing variables for audio data include the number of samples persecond, the number of channels (e.g., mono, stereo, 5-channel) and thesample size (8-bit, 16-bit, etc.). Different settings may be necessaryto ensure audio quality in light of a particular content type andbit-rate. Publishing variables may also include the size of data packetsbeing sent and the choice of transmission protocol (e.g., TCP vs, UDP).

FIG. 7 shows an example transcoder that transcodes on demand source typemedia content 610 to destination type media content 650. Source typemedia content 610 is digital data delivered over a network in one ormore packets. The digital data that forms source type media content 610is defined by one or more publishing variables. The publishing variablesas shown in FIG. 7 include one or more of the following variables:source file format, source bit rate, source physical medium, sourcecommunication protocol, source encoding, or any combination thereof.Destination type media content 650 is digital data delivered over anetwork in one or more packets to an end user that demands the mediacontent. The digital data that forms destination type media content 650is also defined by one or more publishing variables. The publishingvariables as shown in FIG. 7 include one or more of the followingvariables: destination file format, destination bit rate, destinationphysical medium, destination communication protocol, destinationencoding, or any combination thereof.

FIG. 8 shows a table of an example implementation where one or moretranscoders transcodes on demand from a source type media content 710 toa first destination type 750. FIG. 8 also shows an exampleimplementation where one or more transcoders transcodes on demand from asource type media content 710 to a second destination type 760. Thesource type media content 710 includes digital data published accordingto the following source publishing variables: namely, the physicalmedium is a local disk, the communication protocol includes a file I/O,the file format is MP3 using MP3 encoding at a bit rate of 128 kilobitsper second (kbps). The first destination type media content 750 includesdigital data transcoded for publication according to the followingdestination publishing variables: namely, the physical medium is apacket-switched network (the Internet), the communication protocolincludes WINDOWS MEDIA STREAMING MMS protocol, the file format isWINDOWS MEDIA FILE, using MP3 encoding at a bit rate of 56 kbps. Thesecond destination type media content 760 includes digital datatranscoded for publication according to the following destinationpublishing variables: namely, the physical medium is a Wireless Network,the communication protocol includes HTTP, the file format is MP3including MP3 encoding at a bit rate of 12 kbps.

Other examples are shown in the following tables:

Tables 2-5: Example Transcoder Operations

TABLE 2 Publishing Variables Source Type Destination Type physicalmedium Disk Network communication protocol(s) File I/O RTSP containerformat MPEG1 QUICK TIME encoding MPEG1 SORENSON (video) QDESIGN (audio)bit rate 1.5 Mbps 300 kbps

TABLE 3 Publishing Variables Source Type Destination Type physicalmedium Wired Network Wireless Network communication protocol(s) HTTP MMScontainer format MPEG1 WINDOWS MEDIA encoding MPEG1 MPEG4 (video)MSAUDIO (audio) bit rate 1.5 Mbps 100 kbps

TABLE 4 Publishing Variables Source Type Destination Type physicalmedium Wired Network Wired Network communication protocol(s) HTTP RTSPcontainer format QUICK TIME REAL encoding H.263 REAL PROPRIETARY G2Video/Audio bit rate 56 kbps 56 kbps

TABLE 5 Publishing Variables Source Type Destination Type physicalmedium Disk Wireless Network communication protocol(s) File I/O HTTPcontainer format MPEG1 MP3 encoding MPEG1 audio only - MP3 bit rate 1.5Mbps 16 kbps

FIG. 9 is a table showing exemplary client environment variable typesaccording to an embodiment of the invention. The system of the preferredembodiment is capable of determining further characteristics of clientsystems including operation system (OS) versions, web browser versions,hardware platforms and user interface languages. This capability is anadvantageous improvement even over a system that includes theadvantageous ability to discern which type of OS, e.g., Windows, Mac orLinux, is being used on the client machine. For example, even if it isknown the system uses Windows, an assumption of a version more recentthan the client actually has could result in complete failure of themedia stream and a conservative assumption of a much earlier version canresult in inefficiencies.

An, example is provided of a source type 810, i.e., where the mediacontent is coming from and configured for initially, having Window XP asits OS version, Navigator 3.0 as its browser version, a Pentium 4processing chip installed and using Javascript for Navigator 3.0 as itsuser interface language. These source types may be provided ordetermined similar to the determination of the client configurationdescribed in accordance with an embodiment herein. Then, the destinationtypes 850 are illustrated as being Mac OS X operating system, Omniweb4.1 web browser version, a G3 processor chip, and user interfacelanguage XSLT for Omniweb 4.1. Once the destination types 850 areremotely determined according to an embodiment herein, and the sourcetypes 810 are also determined, then an advantageous transcoding processsuch as may preferably be described at U.S. patent application Ser. No.10/644,602, incorporated herein by reference, may be used to stream themedia content provided from the source to the destination,notwithstanding the different types of hardware and software being used.

These examples are illustrative and not intended to limit the presentinvention. Other types of on demand transcoding operations that areknown now or developed in the future can be used as would be apparent toa person skilled in the art given this description.

ALTERNATE EMBODIMENTS

Example embodiments of the methods and systems of the present inventionhave been described herein. As noted elsewhere, these exampleembodiments have been described for illustrative purposes only, and arenot limiting. Alternate embodiments, differing slightly or substantiallyfrom those described herein, will be apparent to persons skilled in therelevant art based on the teachings contained herein. For example, oneskilled in the relevant art will appreciate that the transcoding systemand method of the present invention is not limited to the transcodingand delivery of media content alone, but also encompasses thetranscoding and delivery of information of all types, including, but notlimited to compressed files, electronic documents, HTML pages, XMLdocuments, and any other information that can be stored in a pluralityof formats and delivered electronically. Other alternate embodimentsinclude, but are not limited to, hardware, software, andsoftware/hardware implementations of the methods, systems, andcomponents of the invention. Such alternate embodiments fall within thescope and spirit of the present invention.

Also, systems and methods for the on-demand transcoding of media contentfrom a source type to a destination type may be provided, wherein thesystem includes a plurality of transcoders for transcoding from aplurality of source types to a plurality of destination types, andwherein the system receives a transcoding request for media content,fetches the media content in response to the transcoding request, sendsthe media content to one of the plurality of transcoders based on thesource type and destination type, transcodes the media content from thesource type to the destination type, thereby generating transcoded mediacontent, and transmits the transcoded media content. The system mayfetch, send, and transcode the media content and transmit the transcodedmedia content in a pipelined fashion. The system may also provide forthe publication of media content as a file or stream of digital data,for the archiving of media content, and the caching of transcoded mediacontent to improve system efficiency.

In addition, in methods that may be performed according to preferredembodiments herein and that may have been described above, theoperations have been described in selected typographical sequences.However, the sequences have been selected and so ordered fortypographical convenience and are not intended to imply any particularorder for performing the operations.

1-74. (canceled)
 75. A method for remotely determining the configurationof a computer of a multimedia content user, comprising: (a) sendingplayer detection code the user's computer; and (b) receivingconfiguration information regarding the user's computer, saidconfiguration information comprising: (1) OS version; (2) web browserversion; (3) hardware platform; (4) user interface language type; (5)encoding format; or (6) compression algorithm; or (7) combinationsthereof.
 76. The method of claim 75, further comprising setting a cookieat the user's computer to a domain of a delivery management server,performed before said receiving, and wherein the configurationinformation is received in the cookie.
 77. One or more processorreadable storage devices having processor readable code embodiedthereon, said processor readable code for programming one or moreprocessors to perform a method of for remotely determining theconfiguration of a computer of a multimedia content user, the methodcomprising: (a) sending player detection code the user's computer; and(b) receiving configuration information regarding the user's computer,said configuration information comprising: (1) OS version; (2) webbrowser (3) hardware platform; (4) user interface language type; (5)encoding format; or (6) compression algorithm; or (7) combinationsthereof.
 78. The one or more storage devices of claim 77, the methodfurther comprising setting a cookie at the user's computer to a domainof a delivery management server, performed before said receiving, andwherein the configuration information is received in the cookie.